1. Tracking and Message Management
Now that you have seen how
BizTalk stores, routes, and publishes messages, the next step is to
understand how those messages can be tracked and what happens to them
once they have been processed. Each subscriber of a particular message
references the same single copy of that message. This approach requires
that a reference counter be kept for all messages flowing through the
system. Although this minimizes storage, it requires that the messages
be cleaned up once their reference counters reach 0. To accomplish this,
the product includes a set of SQL Agent jobs that perform garbage
collection for zero-reference-count messages and message parts. The
stored procedures that handle garbage collection are as follows:
MessageBox_Message_Cleanup_BizTalkMsgBoxDb: Deletes all messages that have no references by any subscribers.
MessageBox_Parts_Cleanup_BizTalkMsgBoxDb:
Deletes all messages that have no references by any messages.
PurgeSubscriptionsJob_BizTalkMsgBoxDb: Deletes unused subscription predicates leftover from system-created subscriptions.
MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb:
Executed when the runtime detects that a server has crashed. This frees
the work that the server was working on so another machine within the
group can process it.
TrackedMessages_Copy_BizTalkMsgBoxDb:
Copies tracked message bodies from the Messaging Engine spool tables
into the tracking spool tables in the Messagebox database.
TrackingSpool_Cleanup_BizTalkMsgBoxDb:
Removes the message body data from the database table to which the
TrackedMessages_Copy_BizTalkMsgBoxDb SQL Server Agent job writes.
The first two items from the
preceding list are used to keep garbage messages removed from the
Messagebox. When executed, they search the messages and message parts
within the Messagebox looking for messages with a reference count of
zero. The stored procedures also check for parts that are not referenced
by any messages and remove those as well. Once messages are ready to be
removed, they are moved to the BizTalk Tracking Database. These two
jobs are executed from the machine that hosts SQL Server. For these jobs
to run, the SQL Server Agent needs to be running. If SQL Server Agent
isn't running, tracked message bodies will never be offloaded to the
Tracking Database, and hence the Messagebox will grow. As the database
grows, performance will suffer, because the number of messages grows
unchecked. This is because the Message Agent that is running within each
BizTalk host will be calling a stored procedure that searches through
each of the messages in the Messagebox looking for messages with
matching subscription information.
To keep the Messagebox as
empty as possible, the tracking subsystem will move completed messages
to the Tracking Database on a periodic basis. This is accomplished by a
BizTalk host that has been tagged as a "tracking" host by specifying an
option in the Host Properties page. The Tracking Database is also where
the MMC queries for data and displays its tracking information.
2. Handling Failed Messages and Errors
With BizTalk 2009 you have
two options to get at suspended messages. The first option is to use
MMC and process suspended messages manually. Although this is acceptable
when you have to process only a few messages, this option can become
very time- and labor-consuming if you have to deal with a large number
of suspended messages. The second, and in most cases better, option is
to automate the process using a set of context properties available to
be subscribed on. Error handling context properties are defined within
the http://schemas.microsoft.com/BizTalk/2005/error-report property schema. The new context properties are as follows:
What needs to be done is to
ensure that any receive ports that need to have error handling included
have the Generate Error Report check box selected, as shown in Figure 1.
This will signal the runtime engine to generate the routing failure
message and publish it to the Messagebox. Since the message is
published, there needs to be a subscription available to receive the
routing failure message. To that end, you can create an orchestration
that is direct-bound
to the Messagebox through a receive port. The Receive shape in the
orchestration will have a filter criteria specified that sets the
subscription information so that it will receive all failed routing
messages.
To implement the routing, the filter expression needs to be set to "ErrorReport.ErrorType == Failed Message," as shown in Figure 2.
This will cause the
subscription to be written that will receive all suspended messages.
From here, once you have a copy of the failed message within the
orchestration, you can send it wherever you need. An example would be to
have the orchestration send the message to an e-mail address or to an
offline database for examination. All these options will be quite easy
to implement since the message has been parsed and routed to the
orchestration. Note that if you enabled routing for failed messages, no
suspended messages will show up in MMC, and therefore no manual
processing options will be available. You have to design your automated
error handling routine to be an adequate replacement of the
functionality available in MMC.
